-
-
Notifications
You must be signed in to change notification settings - Fork 14.2k
Remap both absolute and relative paths when building rustc and std
#150283
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
Some changes occurred in src/tools/compiletest cc @jieyouxu The rustc-dev-guide subtree was changed. If this PR only touches the dev guide consider submitting a PR directly to rust-lang/rustc-dev-guide otherwise thank you for updating the dev guide with your changes. cc @BoxyUwU, @jieyouxu, @Kobzol, @tshepang The run-make-support library was changed cc @jieyouxu |
This comment has been minimized.
This comment has been minimized.
bd16ded to
4d839da
Compare
|
@bors try jobs=dist-x86_64-linux |
Remap both absolute and relative paths when building `rustc` and `std` try-job: dist-x86_64-linux
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| // and for working directory) so let's remap the build directory as well. | ||
| format!("{}={map_to}", self.build.src.display()), | ||
| ] | ||
| .join("\t"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remark: technically, I think filename parts of Windows(?)/Linux(?) paths can actually contain tabs, however, other tools have the tendency to also break on those, so I'm not worried about that possibility...
|
@bors r+ rollup |
|
@bors rollup=never (for bisection purposes) |
Turns out #150110 didn't work as expected, because when the standard library sources are present, we helpfully un-remap the paths to the local directory of the user, including when we are building the compiler and standard library it-self (duh!), and since those paths are absolute (not relative), our purely relative remapping didn't pick them up.
This behavior wasn't a issue before because the un-remap logic immediately tries to remap them again, and since we had the absolute remapping we would just remap them to the the same thing.
To fix that issue I've adjusted our remapping to remap both the absolute and relative paths when building
rustcandstd, as well as added a run-make to make sure we don't regress it again (with a newneeds-std-remap-debuginfodirective).r? @jieyouxu